perm filename CLOOPS.MSG[COM,LSP]7 blob
sn#858001 filedate 1988-06-02 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂16-May-88 1139 Common-Lisp-Object-System-mailer CLOS document numbers for June meeting
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88 11:37:59 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:37:44 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25773g; Mon, 16 May 88 11:13:24 PDT
Received: by sunvalleymall id AA28381g; Mon, 16 May 88 11:16:26 PDT
Date: Mon, 16 May 88 11:16:26 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161816.AA28381@sunvalleymall.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS document numbers for June meeting
CLOS chapters 1&2: 88-002R
CLOS chapters 3: 88-003R
∂16-May-88 1524 Common-Lisp-Object-System-mailer Chapter 2
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
New Chapter 2 files are now available as functi.*[cls,lsp] on sail.
This material should now be up-to-date except for whatever we decide
to do with check-keyword-arguments.
Please send comments and corrections to me by Thursday morning.
-lgd
∂17-May-88 1340 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 May 88 13:40:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 88 13:38:44 PDT
Date: 17 May 88 13:38 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 May 88 13:56
PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880517-133844-2742@Xerox>
I have no worries that someone who is writing his own version
of make-instance could look in chapter 3 or 4 to find out how to do
error checking. Therefore, only a check-keyword-arguments that is
more generally useful justifies going beyond specifying a
procedural definition of make-instance that is reasonable only for
correct invocations of it.
I am now satisfied that your more general version of check-keyword-arguments can
be useful. It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.
∂18-May-88 1101 Common-Lisp-Object-System-mailer
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 May 88 11:01:24 PDT
Received: by ti.com id AA20889; Wed, 18 May 88 07:13:51 CDT
Received: from Jenner by tilde id AA06761; Wed, 18 May 88 07:12:44 CDT
Message-Id: <2788949394-1458237@Jenner>
Date: Wed, 18 May 88 07:09:54 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments
In-Reply-To: Msg of 17 May 88 13:38 PDT from Danny Bobrow <Bobrow.pa@XEROX.COM>
I am now satisfied that your more general version of check-keyword-arguments can
be useful. It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.
I agree.
Patrick.
∂18-May-88 1818 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 18:18:27 PDT
Date: Wed, 18 May 88 21:22:40 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380679.880518.MOON@AI.AI.MIT.EDU>
1-12 fourth bullet: typos "an :documentation", "documentation documentation"
1-30 first bullet, also second dash bullet: These say an error is
signalled if call-next-method is called when there is no next method.
I thought we changed that to call a generic function whose name escapes
me at the moment, whose default method signals an error.
1-31 last bullet: ditto
1-35: Should the four simple mechanisms listed be augmented with
shared-initialize as a fifth bullet?
1-38 4th paragraph: maybe this should be "initialize-instance or
shared-initialize methods should be used instead."
1-39 penultimate paragraph: shared-initialize does not take three
arguments, it takes two required arguments plus a set of &key arguments.
The initialization arguments are passed as separate arguments, not as a list.
1-40 first paragraph after first three bullets: should be "whose first
parameter specializer is the class standard-object".
1-41 1st paragraph: same comment as 1-39.
1-41 last line: the parameter name is instance, not class, and the
parameter specializer is standard-object, not standard-class.
1-43 4th paragraph: There is a stray sentence fragment "the value
of the shared slot in the old class."
1-43 6th paragraph: I think this should mention that the process can
also be triggered by an explicit call to the function make-instances-obsolete.
1-44 6th paragraph: Rather than saying update-instance-for-redefined-class
takes an &rest argument which is a list of initialization arguments, I
believe it is more correct terminology to say that it takes &key arguments
which are the initialization arguments. The default method may receive these
with an &rest parameter, but the generic function's lambda-list says &key,
not &rest.
1-44 last paragraph: same comment as 1-39.
1-46 penultimate paragraph: same comment as 1-44 6th.
1-47 last paragraph: same comment as 1-39.
1-48 3rd paragraph: same comment as 1-44 6th.
1-48 last paragraph: same comment as 1-39.
∂18-May-88 2007 Common-Lisp-Object-System-mailer Comments on new draft chapter 2 (dated May 16 15:09)
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 20:06:58 PDT
Date: Wed, 18 May 88 23:11:11 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 2 (dated May 16 15:09)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380731.880518.MOON@AI.AI.MIT.EDU>
There is also one comment on chapter 1 in here.
2-6 first paragraph: I'm not sure what is meant by behavior intrinsic to a
generic function itself. I think this probably means a contract that all
methods must obey (as distinguished from idiosyncratic behavior of one
particular method).
2-12: This says call-next-method signals an error, but I thought we
changed it to call a generic function whose default method signals an error.
2-15: In the defmethod, change "&rest initargs" to "&key" for better style,
since this method doesn't use or define any initargs, it should have an
empty set of &key parameters. Also this method should be a :before method;
not a :after method, because we want to initialize the slots ourselves,
not let the primary method initialize them from initforms then reinitialize
them ourselves. I think 1-44 and 1-47 should be modified to reflect this
valid use of :before methods for the two update- functions; they differ
in this respect from initialize-instance and reinitialize-instance.
2-17: The method signatures imply that only standard classes have names,
but I believe the intent was that all classes have names. Certainly
built-in and structure classes do have names.
2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was ambiguous.
What we mean is that the symbol is syntactically valid for use as a
variable name, what we don't mean is that referencing a variable with
this name will access the slot. This should be rephrased if possible.
2-33 last paragraph: The value returned by define-method-combination
should be the method combination meta object (now that we have them),
not the name.
2-37 2nd paragraph: I don't understand what this paragraph is doing
here. Keyword options to what? Did this paragraph drift in from
somewhere earlier in the define-method-combination section perhaps?
2-43: There is documentation for slot descriptor objects now too.
Since only chapter 3 describes those, I don't know whether slot
documentation should be documented in the normal way, or just
mentioned as a remark. I think I prefer the former.
2-45 4th paragraph: Because of the way rule 4 for lambda-list
congruence is defined, I think this has to speak not of the old
and new lambda-lists for the generic function being congruent,
but of the new lambda-list for the generic function being congruent
with the lambda-lists of all existing methods. If an implementation
can sometimes optimize this into a comparison with the old lambda
list for the generic function, that's merely an optimization.
2-55 2nd paragraph: I don't think the system supplied primary
method for initialize-instance checks the validity of the arguments,
since chapter 1 says make-instance takes care of that. Unlike
reinitialize-instance, initialize-instance is not meant to be
called by the user.
2-55 Remarks field: This is not really accurate, as the generic
functions for which methods can be defined varies. Chapter 1
describes this better, maybe the description should not be
repeated here. It would be useful to have a remark that the programmer
is intended to define :after methods for initialize-instance.
2-58: Formatting of method signatures is particularly ugly here.
How about right-justifying "[Primary Method]" throughout this chapter?
2-74,5,6: Are you sure slot-boundp, slot-exists-p, and slot-makunbound
are generic? slot-value isn't. I guess Gregor has final say on this point.
2-85: Same comments as for 2-15.
2-90 first remarks paragraph: same comment as for 2-45.
2-92: with-slots should cross-reference with-accessors
∂19-May-88 1613 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I want to present one more alternative to the initargs checking
problem. This alternative was the result of a couple of hours'
discussion with Guy Steele tuesday night. There are two parts to
it. One is the real technical proposal, and the remainder is the
packaging for chapter 1.
We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.
Then we could write make-instance like this:
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(union
(compute-applicable-methods #'allocate-instance `(,class))
(union
(compute-applicable-methods #'initialize-instance `(,proto nil))
(compute-applicable-methods #'shared-initialize `(,proto))))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'valid-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
Or something like this: the details of the code are not important
for chapters 1 and 2.
This is not a very simple piece of code to present in chapter 1. So
the proposal requires a sample of how to explain this:
\beginsubSection{Definitions of Make-Instance and Initialize-Instance}
The generic function {\bf make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:
\screen!
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
...
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
(defmethod make-instance ((class-name symbol) &rest initargs)
(apply #'make-instance (find-class class-name) initargs))
\endscreen!
The elided code in the definition of {\bf make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a slot nor supplied an argument
to an applicable method. This check could be implemented using the generic
functions {\bf class-prototype}, {\bf compute-applicable-methods}, {\bf
valid-keywords}, and {\bf class-slot-initargs}. See Chapter~3 for a
description of this initialization argument check.
The generic function {\bf initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:
\screen!
(defmethod initialize-instance ((class standard-class) &rest initargs)
(apply #'shared-initialize instance t initargs)))
\endscreen!
These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.
Customizing at the Programmer Interface level includes using the {\bf
:initform}, {\bf :initarg}, and {\bf :default-initargs} options to
{\bf defclass}, as well as defining methods for {\bf make-instance}
and {\bf initialize-instance}. It is also possible to define
methods for {\bf shared-initialize}, which would be invoked by the
generic functions {\bf reinitialize-instance}, {\bf
update-instance-for-redefined-class}, {\bf
update-instance-for-different-class}, and {\bf
initialize-instance}. The meta-object level supports additional
customization by allowing methods to be defined on {\bf
make-instance}, {\bf default-initargs}, and {\bf
allocate-instance}. Chapters~2 and~3 document each of these generic
functions and the system-supplied primary methods.
Implementations are permitted to make certain optimizations to {\bf
initialize-instance} and {\bf shared-initialize}. The
description of {\bf shared-initialize} in Chapter~2 mentions the
possible optimizations.
Because of optimization, the check for valid initialization arguments
might not be implemented using the generic functions {\bf
class-prototype}, {\bf compute-applicable-methods}, {\bf valid-keywords},
and {\bf class-slot-initargs}. In addition, methods for the generic
function {\bf default-initargs}, and the system-supplied primary methods
for {\bf allocate-instance}, {\bf initialize-instance}, and {\bf
shared-initialize} may not be called on every call to {\bf make-instance}
or may not receive exactly the arguments that would be expected.
\endsubSection%{Definitions of MAKE-INSTANCE and Initialize-Instance}
∂20-May-88 1508 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 15:08:46 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 88 17:32-EDT
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
These comments come from someone who has been keeping an eye on the
cl-o-o-p mail, but hasn't been reading the specs regularly and closely.
I'm omitting remarks which would overlap those in
<380679.880518.MOON@AI.AI.MIT.EDU>
A general remark on all of the documents -- as a non-American and as
something of a pedant I feel my blood-pressure rising every time I
encounter ``congruent with'' or ``different than'' in the documents (as
opposed to ``congruent to'' and ``different from'' respectively.) Is
this really Standard American English?
Another general remark is that Chapter 1 and Chapter 2 do not stand very
well apart from Chapter 3 -- there are too many functions mentioned in
passing which are never defined in any further fashion (or even
mentioned again!) This certainly makes for rather hard reading and
comprehension.
1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.''
1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.
1-31 2nd PP. ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.'' The uppercase text seems redundant.
1-31 5th PP. I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...''
1-32 <foo>
1-33 Penultimate PP. I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...'' should read just ``the classes standard-method, ...''? The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.
1-39 3rd PP. I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.) ``Inherited'' seems more
straight-forward to me. This is probably just a personal preference.
1-39 Table. The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2). Is this the intent? It seems to unnecessarily constrain the
behaviour of default-initargs methods.
1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.
At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that. For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'
1-39 Last PP. I would write ``The second argument to shared-initialize
may be one of the following:''
1-40 First (bulleted) PP. What if the instance doesn't have a slot with
named by one of the elements of the list? Is it ``an error?'' Is
slot-missing called?
1-40 4th bulleted PP. It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.'' or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg. I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.
1-41 `Definitions of make-instance and initialize-instance'
I think that it would make the manual a lot easier to read if similar
sample definitions were provided for the other initializations methods
(reinitialize-instance, update-instance-for-xxx, ...) I think that
moving this section of sample definitions forward in the manual (perhaps
before the `shared-initialize' section, perhaps even very early in
`Objection Creation and Initialization') would provide much better
understanding of what the various generic functions do.
This would also somewhat alleviate my above-mentioned problems with
the unmotivated appearance of `shared-initialize.'
When I started reading from `Object Creation and Initialization' I
encountered a whole slew of names of generic functions on which I would
define methods, but no real reason for why I should want to do so for
around 7 more pages.
I personally find it much easier to be presented with an overall
framework of code and then later `fill in the blanks' by reading what
the purpose of the various functions are than to wade though pages of
passing references to lots of functions before discovering how they fit
together and how they are supposed to be useful.
1-41 Definition of make-instance. Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs? It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself!
My first reaction to this is to suggest a definition like:
(defmethod make-instance ((class standard-class) &rest initargs)
(apply #'with-defaulted-initargs
(lambda (&rest defaulted-initargs)
...initarg error-checking code...
(let ((instance (apply #'allocate-instance
class defaulted-initargs)))
(apply #'initialize-instance instance defaulted-initargs)
instance))
class initargs))
[where any implementation worth its salt would provide some way to
declare the dynamic extent of the INITARGS argument and the
LAMBDA-expression.]
Of course there are other ways to do this sort of thing.
I don't believe that the permissible optimizations mentioned are
sufficient to stop me worrying about this point.
So, has nobody else considered this issue, or does nobody else
consider it an issue?
1-41 Last PP. What ``certain optimizations are permitted.'' Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize. The Chapter 2
description of shared-initialize explains this -- there should be some
xref.
1-42 Last PP. I found this hard to read. Suggestion:
``As a result of various optimizations, not all of the functions and
methods involved in initialization need necessarily be called on every
call to {\bf make-instance} and, if called, they may not receive exactly
the arguments that one would expect based on the sample implementation
above.''
The example of a permitted optimization is bogus, because
check-keyword-arguments is not a method, and so the user has no business
redefining it, and so user methods have no way of telling whether it has
already been called or not (since it is stated that it won't signal an
error.)
My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document. I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.
1-43 6th PP. The aside ``This two-step process ...'' disrupts the
description of what the process is. Is should be moved below, after the
sentence ``... and other user-defined actions.''
1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed. For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
Secondly, I don't think much would be lost be replacing each occurrence
of the intrusively-long
Initialization arguments are declared as valid by using the {\bf
:initarg} option to {\bf defclass} or by defining methods for {\bf
<method-name>} or for {\bf shared-initialize}. See the section
``Declaring the Validity of Initialization Arguments'' for more information.
with simply:
(See the section ``Declaring the Validity of Initialization Arguments''
for more information.)
Here's a suggested rewrite (I'd find code easier to read than this
turgid techno-English any day...):
There is a system-supplied primary method for {\bf
update-instance-for-redefined-class} whose parameter specializer for
its instance argument is the class {\bf standard-object}. This
method first checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared as valid. (See the section ``Declaring the Validity of
Initialization Arguments'' for more information.) Then it calls the
generic function {\bf shared-initialize} with arguments of the
instance, a list of names of the newly added slots, and the
initialization arguments it received.
The now-redundant second half of the descriptions of these methods (with
appear in the ``Customizing foo'' sections) could be replaced by just
Methods for {\bf shared-initialize} may be defined to customize class
redefinition. See the section ``Shared-Initialize'' for more
information.
Finally, just to be contentious (I'm not inviting replies):
* I'm still convinced (after two years (even after reading all the
archived mail on the subject)) that optionals should be defaulted in the
generic function rather than the methods.... Oh well.
* I think it is a real loss that there is no way of specifying an
`interface function' such as New Flavors has. The mess with the stupid
optional arg for DOCUMENTATION methods in chapter 2 is an example of
this.
* I'm aware of the problems they entail -- however I still find it a
pity that there is no provision for `private' methods and slots.
* I find the omission of defclass :constructors to be a significant
loss, based on past experience with implementing this sort of thing.
* I rely upon and heavily use New Flavors defun-in-method. I don't see
how I could get equivalent performance via the use of WITH-SLOTS (since
I don't believe (the equivalent of) usage of a mapping table will be done
outside of method bodies.)
* I think that the use of STANDARD method combination for the various
initialization methods is a mistake. It is too easy (for a ready
example, see the mistake Moon pointed out in <380731.880518.MOON@AI.AI.MIT.EDU>
about 2-15) to bash the useful system-defined method. It is not at all
clear to me that it is ever useful to do this deliberately -- the only
thing it could do (which could not be done by defining an `auxiliary'
method on it or on shared-initialize) is inhibit error-checking.
I hold that the `two-pass' method-combination used in Flavors for
initialize-instance is the right sort of thing: initialize-instance and
reinitialize-instance should use `progn-with-:after' method combination,
and update-instance-for-redefined-class and
update-instance-for-different-class should use `progn-with-:before'
method combination (I can't think of a use for :after methods on these
gf's.)
Besides, use of non-STANDARD method-combination would actually show
readers that all this method-combination hair is actually good for
anything!
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
* IWBNI GET and (SETF GET) were made generic, though I suppose the same
sort of argument could be made for dozens of other CLtL functions.
∂20-May-88 1703 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88 17:03:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408054; 20 May 88 20:02:25 EDT
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521000213.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Comments on a subset of your comments, not to imply that the remainder
should be ignored. In general I agree with them.
1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.
I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function." Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled." Not
that I am a fan of implementations that allow you to turn off error checking.
1-32 <foo>
I don't follow.
1-33 Penultimate PP. I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...'' should read just ``the classes standard-method, ...''? The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.
No, the text is correct as it stands. Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.
1-39 3rd PP. I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.) ``Inherited'' seems more
straight-forward to me. This is probably just a personal preference.
"Captured" refers to lexical capturing, not class inheritance. I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.
1-39 Table. The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2). Is this the intent? It seems to unnecessarily constrain the
behaviour of default-initargs methods.
"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.
1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.
The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)
At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that. For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'
The false connotation of shared slots is the same comment I had. However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.
1-40 First (bulleted) PP. What if the instance doesn't have a slot with
named by one of the elements of the list? Is it ``an error?'' Is
slot-missing called?
You're right, we need to specify this. Let's make it "the results are
unspecified."
1-41 Definition of make-instance. Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs? It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself!
Of course. But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations. I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff. Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.
Finally, just to be contentious (I'm not inviting replies):
Yes, CLOS definitely has that design-by-committee aroma.
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
I don't understand your point. How is define-method-combination different
from defmacro in this respect? Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?
∂20-May-88 2010 Common-Lisp-Object-System-mailer check-keyword-arguments
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88 20:09:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191392; Fri 20-May-88 23:08:50 EDT
Date: Fri, 20 May 88 23:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 19:13 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880521030857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 May 88 1613 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I want to present one more alternative to the initargs checking
problem.
[Getting rid of check-initargs & successors, writing the code inline,
and putting it in chapter 3.]
This sounds good to me, with a couple modifications suggested below.
Let's go with it.
We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.
function-keywords would be a better name. Otherwise okay.
I have no quarrel with the dual return values.
[Yes, I know (subtypep 'method 'function) => nil t. Nonetheless,
in this context the method is used in a functionesque way.]
I assume method-applicable-keywords, p.27 of the most recent draft
of ch.3 that I've seen (the one handed out at X3J13 in March), would
go away.
Then we could write make-instance like this:
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(union
(compute-applicable-methods #'allocate-instance `(,class))
(union
(compute-applicable-methods #'initialize-instance `(,proto nil))
(compute-applicable-methods #'shared-initialize `(,proto))))))
I think you want append rather than union, since there won't be any
methods in common between distinct generic functions. Also the args for
initialize-instance and shared-initialize have accidentally gotten
interchanged.
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'valid-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
∂20-May-88 2206 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I think Moon's suggestion for the name FUNCTION-KEYWORD is acceptable.
Here is the corrected code (Having Moon around to read code is
almost as good as having a computer. In fact, it's better because
sometimes he cracks a joke.):
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'function-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
∂21-May-88 0017 Common-Lisp-Object-System-mailer Mlynarik's comments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
First I'll address the general grammatical comments. As far as I can tell
by reading the OED, ``congruent with'' is standard British English. Using
Webster's Second Unabridged - the most prescriptive American English
dictionary - I find ``congruent with'' used in general contexts and in
most mathematical contexts. My perusal of math texts seems to indicate
``congruent to'' is acceptable when discussing number theory. I cannot
find explicit grammatical justification for ``congruent to'' in any
context. Because we are not talking about number theory, I don't believe
any changes are necessary.
It is currently correct to use the following rules for ``different'': The
phrase ``different from'' is used when introducing a phrase while
``different than'' is used when introducing a clause. My references claim
``different from'' and ``different than'' have both appeared for the
last 300 years. British usage admits ``different to.''
Note there is no use of ``different than'' (or ``different from'')
in chapter 1.
To comment further on the grammar in chapters 1 and 2. Linda and I are
both relatively careful writers in terms of grammar, and I can assure you
that we have not dashed off this piece. Furthermore, we have engaged copy
editors to proofread major drafts of these chapters before they are sent
out. The style of writing might be academic, but I believe it corresponds
to acceptable Amercian English in all cases, and even the editors of the
OED now accept American usage as standard.
The remainder of this message is a response to Richard's comments. I have left
out specific comments to which Moon responded with remarks with which I
agree.
Richard writes:
``1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''
The sentences in question are:
``A method object is not a function and cannot be invoked as a function. An
implementation may extend the \OS\ so that method objects are functions.''
The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations. If we wrote it your way then someone could
legitimately understand that within a single implementation a particular
method object may or may not be a function.
The style we use consistently throughout is to state a constraint
and then allow extensions.
Richard writes:
``1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.''
Moon's remark is correct and the passage has been repaired.
Richard writes:
``1-31 2nd PP. ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.'' The uppercase text seems redundant.''
It is redundant and intentionally so: You cannot possibly misread
the current version. A misreading would be
``To specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as the
argument ... to any of the other forms that specify generic function
options.''
Richard writes:
``1-31 5th PP. I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...'' ''
``Could have been'' but weren't? Your rewrite talks about an implementation
choice that may or may not be relevant, whereas the current language
discusses semantics.
Richard writes:
``1-32 <foo>''
I agree with Richard on the weirdness of this description, but
I could not (and still cannot) think of a more precise approach to
describing this. I have spent weeks on the bulleted item over the
last 2 years.
Richard writes:
``1-39 Last PP. I would write ``The second argument to shared-initialize
may be one of the following:'' ''
Right.
Richard writes:
``1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.''
Right. I added such an introduction to shared-initialize early
in the section.
Richard writes:
``1-40 4th bulleted PP. It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.'' or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg. I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.''
Right.
Richard writes:
``1-41 Last PP. What ``certain optimizations are permitted.'' Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize. The Chapter 2
description of shared-initialize explains this -- there should be some
xref.''
I thought it already cross-references to shared-initialize.
Richard writes:
``1-42 Last PP. I found this hard to read. Suggestion....''
This paragraph has been rewritten based on the newthink on the
check-initargs problem.
Richard writes:
`` My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document. I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.''
Yes, I would like to hear your ideas.
Richard writes:
``1-43 6th PP. The aside ``This two-step process ...'' disrupts the
description of what the process is. Is should be moved below, after the
sentence ``... and other user-defined actions.'' ''
This paragraph is now different enough that this comment isn't as valid.
In particular, other circumstances have been added in which the process
can start up, and the discussion of when it can happen is the current
focus of the paragraph.
Richard writes:
``1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed. For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
....''
Good idea. I've so modified the sections.
-rpg-
∂21-May-88 0651 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 06:51:05 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:51:30 PDT
Received: from bhopal.lucid.com by edsel id AA20037g; Sat, 21 May 88 06:40:47 PDT
Received: by bhopal id AA08392g; Sat, 21 May 88 06:44:29 PDT
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211344.AA08392@bhopal.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Comments on current state of Initialization.
Why should there still be three initialization protocls: "shared-initialize",
"initialize-instance", and "reinitialize-instance" (sp?).
Why not just "initialize-instance" with a keyword argument for whether or
not it is a first-time initialization? In each case, the specialization
needed is over the instance, and not over the slots-for-initforms argument,
or the initargs argument, or any other arugment. And so _most_ of the
processing will be the same regardless of whether the caller is make-instance
or one of the update-instance-for-<munged>-class functions (i.e., whether
initializing afresh or whether re-initializing). In fact, for many classes
I would guess that the particular list given as the 'slots-for-initforms'
argument would adequately cover any necessary distinctions between fresh
allocation and "update-instance-for-<munged>-class". Direct user calls, if
any, could pass this keyword argument, rather than decide between two
differently named functions.
I presume that the main primary method is the one whose chief purpose is to
set slots, first from the initargs and then from the initforms, and that this
wouldn't need to be modified by the user. [In fact, letting the user change
this primary method is probably a mistake.] Again, I would guess that most
user :after methods wouln't be concerned with the distinction between
"fixing up" the initialization of a fresh instance, and that of "fixing up"
the re-setting of slots on an "old" instance; in each case, the more
important information is in the 'slots-for-initforms' argument.
In short, what I fail to see is any justification for hairing up the
protocol to inject a generic function that seems to have no particular
user benefit: reinitialize-instance. Looking over back mail, I find
this one comment from Danny:
Date: 8 Apr 88 15:37 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: (re)initialization revisited
In-Reply-To: kempf@Sun.COM's message of Thu, 07 Apr 88 12:13:45 -0700
To: kempf@Sun.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Jim proposes removing some functions in the spec. I sympathize with this
as a general goal. But in this case I think it is misguided. There are
really four concepts
1) initializate (make a brand new instance have the right state)
2) reinitialize (make an old instance have a "standard" starting state)
3) class-changed (make a change from one form of current instance to another)
4) update-instance-structure (make an appropriate current instance from an
outdated instance.
Because there are four concepts, there must be four entries so that users
can change what is done for each. Collapsing concepts into a commonly
named fn just causes confusion.
. . .
Reinititializing must potentially take into account old values on slots.
Initialization never has to. We introduced the general concept because we
had two examples in CLOS itself that require it: instances of
standard-class, and instances of standard-generic-function. Both must
take into account previous state of the objects to be changed.
But still, this is not justification for imposing a complexity that
will almost never be used by the end user, and for which there is an
adequate alternative: keyword argument to initialize-instance. Note
that there is no need to split off re-initialization due to a difference
in the ways in which it might be specialized.
-- JonL --
∂21-May-88 1602 Common-Lisp-Object-System-mailer define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88 16:02:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191452; Sat 21-May-88 19:01:56 EDT
Date: Sat, 21 May 88 19:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richard MlYNarIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521191828.5.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 15:18 EDT
From: Richard MlynBaOrik <Mly@AI.AI.MIT.EDU>
[common-lisp-object-system@SAIL.STANFORD.EDU removed]
[Added back since I thought it was useful for the whole list to see
the reply. I don't expect I'm embarrassing you.]
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
I don't understand your point. How is define-method-combination different
from defmacro in this respect? Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?
I'm wondering how add-method works.
If one does a random add-method to a generic function (say by loading a
file containing a defmethod form) then whenever the combined
(`effective') method is created (at instance instantiation time or
whenever) something has got to look at the lisp code produced by the
`macroexpansion' of a define-method-combination form. This
macroexpasion can't be performed any earlier, because it depends on the
applicable methods.
That's quite a reasonable concern to have, however we've thought of it.
The compiler can anticipate what add-method calls are going to be
produced by forms the compiler has seen, such as defmethod forms. The
code resulting from method-combination can be predicted at compile time
and compiled then, with a simple mechanism to make sure at load time
that that pregenerated code gets used. This is how it works in Flavors,
so that's an existence proof.
Of course if a program calls add-method at run time in a way the compiler
can't anticipate, such techniques can't win. But I'd say that kind of
program, which changes its structure at run time, should not be surprised
to depend on having a compiler at run time.
As I see it, either the lisp evaluator is used whenever the combined
method is called or else the lisp code produced by
define-method-combination has to be turned into something executable by
`the machine.'
It's also true that an evaluator different from the Lisp evaluator can
be used. For example, the form returned by the method combination
function can be recognized as an instance of a pattern and the effective
method can be a closure of a preexisting function that knows how to
"evaluate" such forms; the enclosed variables typically have methods or
lists of methods as their values. The preexisting functions can even be
generated automatically when the system is compiled, from declarative
specifications (arrange for x type of method combination to work with n
applicable methods in role z). Some types of method combination work
this way in Flavors in 7.2 [oh, I see you know that], and I'm told PCL
also works this way. I assume that CLOS can work this way, too, using
the world's simplest pattern matcher to recognize forms returned by
method combination functions.
∂21-May-88 1605 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88 16:04:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191453; Sat 21-May-88 19:04:12 EDT
Date: Sat, 21 May 88 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805211344.AA08392@bhopal.lucid.com>
Message-ID: <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Why should there still be three initialization protocls: "shared-initialize",
"initialize-instance", and "reinitialize-instance"?
[Summary: replace reinitialize-instance with a keyword argument to
initialize-instance --Moon]
Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; reinitialize-instance is to be
called directly by the user, but initialize-instance cannot be (review how
the keyword arguments get validated).
∂21-May-88 1923 Common-Lisp-Object-System-mailer define-method-combination
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 May 88 19:23:33 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 88 22:24-EDT
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Subject: define-method-combination
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:
define-method-combination should accept an option
(:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.
======================================================================
I only partially believe what Moon says about define-method-combination.
On the whole, I find his arguments unfortunate sorts of thing to have to
claim, especially when there are another ways of declaring method
combination this which avoids this sort of problem. (By constructing
closures rather than s-expressions.)
I do believe his arguments as applied to system-predefined
method-combination -- after all, and as he says, we have Flavors as an
existence proof.
On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time. So I suppose we should say that we would have Flavors as
existence proof in principle...
I very much doubt that a user will in fact be able to declare enough to
the system to generate the same quality of code as the specially-
recognised predefined system method combination types -- let
alone that s/he would be able to declare this is any portable way!
I realize that CLOS is only specifying semantics, but why make things
harder than they need be, so hard they they need a Sufficiently Smart
Compiler Sufficiently Useful Magic-Unspecified-Declarations/
Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
(For years there has been talk about sufficiently smart compilers taking
all of my troubles away, but I've yet to see evidence of such things.)
My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else. The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks. I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system. This certainly does not seem
to be the case with user-defined method-combination types.
(I know there are limits to this argument -- for example I doubt that J.
Random Generic-function Metaclass could expect the same performance as
implementation-tuned standard-generic-function.)
However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler) then why
bother specifying it at all? I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well? Especially, why clutter the world so much the EVAL
becomes required (when nothing else in CLtL except for the section on
the evaluator seems to require such a horrible thing)?
BTW I've looked at the pattern-matchers (by no means ``the world's
simplest'' -- PCL's uses a real code-walker) in both PCL and Flavors and
still doubt that they can do enough before they become full lisp
compilers. (When Flavor's pattern-matcher punts, it ends up calling
compile.)
I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.
I guess Scheme has gone badly to my brain -- the mere hint of run-time
evaluation/compilation makes me feel ill (the symptoms are flames coming
from the mouth.) There is another reason, though: I have recently had
very bad experiences with a very large piece of software which suffered
and suffered (and made me suffer) because of the way it called out to
the evaluator.
Anyway, this whole issue was originally filed under the
``Just to be contentious'' label -- I didn't expect and still do not
expect to convince anybody.
I am not going to continue to flame about this.
∂23-May-88 0644 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 May 88 06:44:34 PDT
Received: by ti.com id AA26663; Mon, 23 May 88 08:43:54 CDT
Received: from Jenner by tilde id AA28453; Mon, 23 May 88 08:31:19 CDT
Message-Id: <2789386229-306446@Jenner>
Date: Mon, 23 May 88 08:30:29 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments
In-Reply-To: Msg of 20 May 88 2206 PDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Date: 20 May 88 2206 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: check-keyword-arguments
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'function-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
I agree, expect that the second value returned by function-keywords needs
to be looked at. Something like this would work (I think):
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(block check-keys
(let ((valid-keys (class-slot-initargs class)))
(dolist (method methods)
(multiple-value-bind (keys allow-other-keys-p)
(function-keywords method)
(if allow-other-keys-p
(return-from check-keys t)
(setf valid-keys (union keys valid-keys)))))
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
valid-keys)))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
Patrick.
∂23-May-88 0842 Common-Lisp-Object-System-mailer Re: define-method-combination
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 May 88 08:42:19 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA04663; Mon, 23 May 88 08:41:00 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA15995; Mon, 23 May 88 08:38:27 PDT
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
id AA04572; Mon, 23 May 88 08:33:04 PDT
Message-Id: <8805231533.AA04572@suntana.sun.com>
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: define-method-combination
In-Reply-To: Your message of Sat, 21 May 88 22:27:00 -0400.
<19880522022721.6.MLY@PERON.AI.MIT.EDU>
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM
>On the other hand, as long as I've been using lisp machines (up to this
>very day) I've encountered combined methods which weren't caught at
>compile-time. So I suppose we should say that we would have Flavors as
>existence proof in principle...
Unfortunately, I suspect that you may be right about this. However, I don't
necessarily believe that this makes user defined method combination types
useless. Certainly, for prototype or experimental code, where performance
is not as critical, they should be useful. And CLOS has been designed
with the needs of experimentalists in mind. There may even be some
applications which don't mind having a full evaluator or compiler around.
In fact, how many Lisp applications run today *without* a full evaluator
or compiler around (rhetorical question, very few I suspect).
>I realize that CLOS is only specifying semantics, but why make things
>harder than they need be, so hard they they need a Sufficiently Smart
>Compiler Sufficiently Useful Magic-Unspecified-Declarations/
>Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
>(For years there has been talk about sufficiently smart compilers taking
>all of my troubles away, but I've yet to see evidence of such things.)
When somebody manages to convince a funding agency like DARPA that
research on advanced Lisp compilers is important, it will happen.
Until then, forget it. Lots of people have plenty of ideas about
how to make Lisp compilers Sufficiently Smart, unfortunately, maintenance
of existing compilers, addition of features (like multiprocessing) and
environmental support have taken precedence in the commercial field,
because that is what customers are asking for. The way things are
currently going, we should be happy if a product quality CLOS is
available within a reasonable amount of time, and I'm not talking about
the technical side of implementing it.
>My overall fear is that this sort of approach will create two classes of
>programs -- those which use the system's predefined method combination
>types and standard method definition (such as defmethod with
>:method-class standard-method) and those which use anything else. The
>first class of programs can expect a much higher level of support than
>the latter, because the compiler has been taught special tricks. I like
>to think that one of the aims of CLOS in general (though Chapter 3-style
>specifications) is to expose as much of the underlying works as is
>necessary to allow non-`standard' classes/method-combination/etc to be
>able to expect a level of support which is at least of the same order of
>magnitude as that provided by the system. This certainly does not seem
>to be the case with user-defined method-combination types.
This is a goal, however, there is a real question of how much the
underlying works can be exposed without constraining the implementation
so much that the standard system defined generic functions and method
combinations can't be compiled efficiently. Unless someone does an
existence proof, it is unlikely that we will really know, because a
paper specification might miss something important. After having tuned
up PCL, I know that the level of metaobject support in PCL can be implemented
very efficiently on stock hardware, however, the version of PCL I used
didn't have method combination, much less user defined method combination.
Of course, any attempt to add additional features invalidates the existence
proof.
>I guess Scheme has gone badly to my brain -- the mere hint of run-time
>evaluation/compilation makes me feel ill (the symptoms are flames coming
More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities.
jak
∂23-May-88 0948 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 09:48:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 09:47:58 PDT
Date: 23 May 88 09:46 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 20 May 88 22:06
PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880523-094758-4593@Xerox>
I am happy to see this version of make-instance PROVIDED we put
compute-applicable-methods and function-keywords in chapter 2. I think both
provide features which are useful to programmers working with CLOS as it stands
rather than with possibly extending the system. compute-applicable-methods is
parallel to find-method, and function-keywords is similar to method-qualifiers,
both of which are in chapter 2. I mildly prefer the name method-keywords since
its argument is a method.I would also suggest find-applicable-methods to
parallel find-method.
∂23-May-88 1047 Common-Lisp-Object-System-mailer More Check-Keyword-Arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I have no problems with compute-applicable-methods and function-keywords
being in chapter 2, except that we are on top of the two-week rule
and have to blast out to make it. Function-keywords is a good name because
it is a generic function, and some Common Lisps might extend it to CL functions.
I preferred valid-keywords because it did not talk about either functions or
methods.
-rpg-
∂23-May-88 1055 Common-Lisp-Object-System-mailer define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88 10:55:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191675; Mon 23-May-88 13:54:24 EDT
Date: Mon, 23 May 88 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880523175424.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:
define-method-combination should accept an option
(:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.
I agree. I think this just got overlooked when :arguments was added,
because before that there wasn't any agreed-upon syntax for saying
things like this. Group: Is there still time to change this?
....
On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time.
And as long as I've been using Lisp, I've encountered files that use a macro
that has been changed, but no one remembered to recompile the file, so the
caller of the macro was not updated. Few people propose to remove macros
from Lisp for that reason. I just don't think your argument is relevant.
....
My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else. The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks.
I agree that that could happen, but I see no reason why it must.
I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system. This certainly does not seem
to be the case with user-defined method-combination types.
I agree with your first sentence, but don't see why you think
user-defined method-combination types are any different from anything
else. Also, you've changed your argument. First you said user-defined
method combination types require the existence of a compiler at load
time (and implicitly you assumed that all Lisps are like most of today's
(but not the 1950's!) Lisps, in that if you have a compiler at load
time, you cannot get rid of it at run time). Now you're saying that
user-defined method combination won't compile as efficiently as standard
method combination, an entirely different argument. I think your new
argument is analogous to saying that it's better to use DO than LOOP,
not because you like the syntax better, but because DO as a built-in
macro is likely to compile more efficient code than LOOP, as a
user-defined macro. That's even true to some extent with some
compilers, but few people change their whole programming style on the
basis of that kind of consideration, and in all the arguments against
LOOP I've heard over the years, I don't recall ever hearing that one.
I really believe that method combination is just like a macro.
However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler)
Please, please, please do not be confused by the interpreter-oriented
presentation, any more than you would be confused by a Lisp textbook which
explained the language in interpretive terms and only introduced the compiler
in a late chapter. Semantics are easier to explain interpretively, but no
one proposes calling out to the evaluator in any real implementation.
then why
bother specifying it at all? I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well?
Change "method combination type" to "macro" and read your argument again.
Of course, there are people in the Scheme community who believe that argument.
I think Common Lisp is way past aspiring to that level of purity, though.
I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.
Of course. It's also trivial to write a program that cannot be compiled.
In practice, people who care about the issue you're concerned with don't
do those things.
∂23-May-88 1105 Common-Lisp-Object-System-mailer Re: define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88 11:05:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191680; Mon 23-May-88 14:05:18 EDT
Date: Mon, 23 May 88 14:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: define-method-combination
To: kempf@Sun.COM
cc: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805231533.AA04572@suntana.sun.com>
Message-ID: <19880523180527.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM
More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities.
I agree with you, but would like to point out that I don't think the
existence of method combination has any bearing on the issue. I think
multiple inheritance and slot access are the areas that cause more
performance impact compared to C++. Furthermore I think the real
performance issues are entirely outside of CLOS, in areas such as
garbage collection and other things that Lisp does for you but C++
does not, and in the fact that the performance comparison is likely
to be on C's "home turf", hardware that is highly adapted for C and
less well adapted for Lisp.
∂23-May-88 1211 Common-Lisp-Object-System-mailer Define-Method-Combination
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I basically agree with Moon's replies to Richard's concerns.
On the topic of the added option to define-method-combination:
define-method-combination should accept an option
(:generic-function <symbol>) and bind <symbol> to the relevant
generic function.
I don't like the name ``:generic-function'' but I cannot think of a
better one. We're moving compute-applicable-methods and function-keywords
into chapter 2 today, so this wrinkle is minor.
-rpg-
∂23-May-88 1234 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
-rpg-
∂23-May-88 1537 Common-Lisp-Object-System-mailer check-keyword-arguments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 May 88 15:37:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 409032; Mon 23-May-88 18:37:03 EDT
Date: Mon, 23 May 88 18:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 May 88 15:34 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523223659.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 May 88 1234 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
Is the name function-arguments a typo?
∂23-May-88 1539 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 15:37:56 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 15:37:54 PDT
Received: from bhopal.lucid.com by edsel id AA01958g; Mon, 23 May 88 15:29:01 PDT
Received: by bhopal id AA01677g; Mon, 23 May 88 15:32:51 PDT
Date: Mon, 23 May 88 15:32:51 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232232.AA01677@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 21 May 88 19:04 EDT <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
re: Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Why should there still be three initialization protocls: "shared-
initialize", "initialize-instance", and "reinitialize-instance"?
[Summary: replace reinitialize-instance with a keyword argument to
initialize-instance --Moon]
Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; . . .
It seemed obvious to me that the "internal" callers from change-class etc.
could just as easily use a simpilifed definition of initialize-instance with
keyword argument.
-- JonL --
∂23-May-88 1600 Common-Lisp-Object-System-mailer check-keyword-arguments etc.
To: moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
Date: 23 May 88 1234 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
Is the name function-arguments a typo?
Yes. It is called function-keywords in the draft that just went out
to the printers.
There are new chapter 2 files out on sail with these additions.
There is also a new macros file that should fix the [Primary Method]
formatting bug.
-lgd
∂23-May-88 1633 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
function-arguments is a typo for function-keywords. That's what I get
for talking on the phone while typing mail.
-rpg-
∂23-May-88 1649 Common-Lisp-Object-System-mailer Re: Mlynarik's comments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 16:49:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 16:46:23 PDT
Date: Mon, 23 May 88 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Mlynarik's comments
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 21 May 88 00:17 PDT from Dick Gabriel
<RPG@SAIL.Stanford.EDU>
Message-ID: <19880523234612.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 21 May 88 00:17 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Richard writes:
``1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''
The sentences in question are:
``A method object is not a function and cannot be invoked as a function. An
implementation may extend the \OS\ so that method objects are functions.''
The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations.
Actually, the second sentence is wrong. We do prohibit them from being
functions in all implementations. Chapter 3 is very clear on this
issue. Methods are instances of the class standard-method which itself
is an instance of standard-class. We should delete the second sentence.
-------
∂23-May-88 1659 Common-Lisp-Object-System-mailer Chapter 1
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The versions of Chapter 1 that are being sent to X3J13 are now
on [cls,lsp] on SAIL. You know what it is; you know what to do.
-rpg-
∂23-May-88 2332 Common-Lisp-Object-System-mailer Method Objects are not Functions
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I don't understand the reasoning that would argue that a method
object a priori cannot be a function.
-rpg-
∂24-May-88 1044 Common-Lisp-Object-System-mailer Re: Method Objects are not Functions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 88 10:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 88 10:43:29 PDT
Date: Tue, 24 May 88 10:43 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Method Objects are not Functions
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 23 May 88 23:32 PDT from Dick Gabriel
<RPG@SAIL.Stanford.EDU>
Message-ID: <19880524174313.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 23 May 88 23:32 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I don't understand the reasoning that would argue that a method
object a priori cannot be a function.
The metaclass of a method object is standard-class. Standard-class does
not support the behavior which allows its metainstances to be
funcallable objects. Only funcallable-standard-class does that.
I suppose that some implementation could extend standard-class to do
that, but I don't see that as a freedom we really need to allow.
-------
∂24-May-88 1105 Common-Lisp-Object-System-mailer Callable Methods
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am aware of the proposed ontology of method objects, but I think we need
to carefully think about how much of the hierarchy to uniquely specify in
Ch3. That is, method objects are things that on the surface could be
callable. Therefore, maybe the metaclass should be something distinct from
from standard-class, but with the proviso that it is acceptable to either
identify this metaclass with standard-class or to hang it under
funcallable-standard-class.
-rpg-
∂26-May-88 1055 Common-Lisp-Object-System-mailer with-added-methods
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 10:54:57 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 May 88 13:55-EDT
Date: Thu, 26 May 88 13:58 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: with-added-methods
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19880526175838.6.MLY@PERON.AI.MIT.EDU>
[Apologies if I am rehashing an issue which has been previously discussed
-- the local CLOS archives are presently inaccessible.]
with-added-methods seems incompatible with the restriction (mentioned in
the doc for add-method) that a method can only be added to one generic
function at a time.
The doc for with-added-methods says:
Each generic function is created by adding the set of methods
specified by its method definitions to a copy of the lexically visible
generic function of the same name and its methods.
That for add-method says:
If the method object is a method object of another generic function,
an error is signaled.
I would think that the new generic function created by
with-added-methods must share all all the methods which were defined on
the original generic function.
I suppose that an alternate reading of the first piece of documentation
is ``to a copy of the lexically visible generic function of the same
name and TO A COPY OF its methods'' -- I'd like to think that this isn't
what was intended, since it would seem to introduce far more problems
than it solves.
Some passing remarks about with-added-methods:
* Does it really need to be a special form rather than a macro?
I -believe- I could define it in terms of generic-flet -- however,'
I haven't thought this through very thoroughly.
* Is there sufficient Chapter 3 support to enable this kind of thing to
be `portably' implemented? Apart from the above-mentioned lossage
involving methods added to more than one generic function, there are
problems brushed under the rug by ``A COPY OF the lexically
visible generic function.'' Presumably there needs to be some
cloning method for generic functions.
* I guess I'll never actually use with-added-methods in any case
because of inefficiencies due what I perceive as the fatal problem
with method-combination...
∂02-Jun-88 1329 Common-Lisp-Object-System-mailer [David N Gray <Gray@DSG>: making structures]
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Jun 88 13:29:15 PDT
Received: by ti.com id AA14212; Thu, 2 Jun 88 15:28:26 CDT
Received: from Jenner by tilde id AA23256; Thu, 2 Jun 88 15:26:36 CDT
Message-Id: <2790274788-645613@Jenner>
Date: Thu, 2 Jun 88 15:19:48 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Common-lisp-object-system@sail.stanford.edu
Subject: [David N Gray <Gray@DSG>: making structures]
I thought I'd pass this along. There is no need to include Gray in the
reply since he is out of town for two month.
------- Forwarded Message
Patrick,
The May 23 draft of the CLOS spec still has the following text on page
1-15: "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS
signals an error." This still seems like an undesirable and unnecessary
limitation to me.
-- David Gray
------- End of Forwarded Message